Various multimedia services have been developed for packet-based communication using IP (Internet Protocol), typically involving transmission of media in different formats and combinations between user terminals such as fixed or mobile computers and telephones. An architecture called “IP Multimedia Subsystem” (IMS) has also been developed to enable such multimedia services and sessions for user terminals connected to different access networks.
Multimedia sessions are handled by specific session control nodes in the IMS network typically using the signalling protocol “SIP” (Session Initiation Protocol) for setup of the sessions. For example, a terminal may send a message called “SIP INVITE” to initiate a session with another terminal or a server, e.g. when a multimedia application has been invoked in the terminal. The SIP INVITE message triggers different actions in the IMS network and the access network for establishing the session, including reservation of appropriate resources in the access network used.
In SIP, an additional protocol called “SDP” (Session Description Protocol) is used for specifying various parameters of a multimedia session, and an SDP message is typically embedded as a self-contained body within SIP messages. SDP messages are used to provide information on terminal capabilities and media properties, in order to specify and negotiate session parameters for multimedia sessions, which is well-known in the art. The session parameters may include terminal capabilities, media properties and address information necessary to establish a session. The above-mentioned SIP INVITE message and a common response message “SIP 200 OK” typically include the embedded SDP message with session parameters proposed by the sender for the session.
A policy node associated with the used access network is also typically connected to the IMS network. Among other things, the policy node controls the reservation of network resources for the sessions, based on various predetermined policies and subscription profiles. In particular, different QoS (Quality of Service) requirements can be enforced by the policy node for different services and/or subscribers for the above resource reservation in the access network, e.g. based on the SDP negotiation above. In multimedia sessions controlled by an IMS network, a desired or expected QoS can be obtained for the participating parties when the policy node controls the reservation of network resources as described above.
When establishing a communication session for a subscriber, various network resources are thus reserved preferably such that an acceptable and expected level of service is maintained for the subscriber, e.g. with respect to data bitrates and latency. When reserving network resources during setup of an IMS-controlled session, any QoS requirements can thus be taken into account.
However, sessions initiated and controlled solely by the participating parties without involving any intermediate session control node or policy node, generally referred to as peer-to-peer sessions, cannot obtain a specific QoS in the manner above. Any data transmitted as data packets between the parties are routed through an IP network, e.g. the Internet, over various routers each having its own mechanisms and policies for controlling different data flows. There is no standardised or consistent mechanism today for ensuring that QoS requirements of the communicating parties are taken into account in the routers. In FIG. 1, a typical scenario is shown for a peer-to-peer session between two user terminals A and B over routers R in an IP network 100. Terminal A is connected to an access router RA and terminal B is connected to another access router RB. The transmission path over multiple intermediate routers R in the network 100 may vary for different data packets during the session, which is well-known in the art.
Today, differentiated services and subscriptions are commonly offered to subscribers of an IMS network such that they can consume services with different subscription types that typically dictate the QoS requirements for those services. The subscribers may thus be offered specific service levels with respect to QoS, e.g. for different subscription types and also for individual services. For example, using common terminology, a “Platinum” subscription may provide a relatively high warranted QoS or service level, whereas “Gold”, “Silver” and “Bronze” subscriptions provide successively lower service levels.
Moreover, specific services may also be offered with different service levels, e.g. at different prices. This differentiation of subscriptions, services and quality/service levels becomes increasingly significant and will thus influence the customer satisfaction and expectations to a great extent. For example, a Bronze subscriber might be satisfied to obtain a certain service level whereas a Platinum subscriber might not, expecting a higher service level.
However, such service levels cannot be guaranteed for peer-to-peer sessions as explained above. Furthermore, when SIP is used to initiate a peer-to-peer session, there is no way to map service level requirements between different operator networks which may have their own definitions of service levels. For example, the commonly used terms Bronze, Silver, Gold and Platinum for different service levels may have different implications in different operator networks with respect to quality related session parameters. Moreover, the sessions need to be symmetrical in terms of using the same quality related session parameters in both directions, in order to achieve a properly working SDP negotiation. Thus, it is a problem that a desired and relevant service level cannot normally be accomplished for peer-to-peer sessions over routers in an IP network not centrally managed, such as the Internet.